* Remove the old point assignments
* Remove the comments describing the pixel offsets from the bottom-left
  of the low battery alert window
* Remove the NSLog for inspecting the frame rect values
* Remove the `width` variable which is no longer used

Previously, the point set to be clicked for the low battery alert was
only valid on a 13" 1440x900 screen. This change allows the click
functionality to work on any screen size.

I discovered in 954071bcc651ed5876d8ac0c3e8c253d4470c416 that I couldn't
use a percentage to get the height of the "OK" button.

But, the low battery alert uses `NSWindow`'s `-center` method, so I
thought up a hack to make a fake window, center it, and get the window's
frame dimensions. The fake window I create has the same (close enough)
dimensions as the low battery alert (measured from a screenshot).

I then use those dimensions to figure out where to click so that I'm
clicking in the right place on the "OK" button.

We also add a check to reinitialise the dimensions and reset the current
window if the main window has changed from what we thought it was. This
should allow the app to still work if you launch it from one display and
later plug in another as your main display where the low battery warning
will now appear.

We need to subtract the frame's Y coordinate from the screen height
because the frame origin uses standard bottom-left origin coordinates,
while `CGDisplayMoveCursorToPoint` uses top-left origin coordinates.

Wanted to get a percentage that I could apply to the height to get to
the right pixel position on the screen, but it doesn't seem like it's
going to be that simple. The percentages are off for a big screen and a
small screen, so I can't rely on a single percentage value.

After some research, my current idea is to make a fake window, call
NSWindow -center on it, and get the coordinates of that window to figure
out where the mouse should be positioned.

Get the shortcut saved from the windows application in our daemon and if
there is one, use that as the hotkey to activate the mouse click.

Yay! This is coming together!

Don't keep allocating and releasing `Mouse` objects when the hotkey is
pressed. Instead, allocate a single instance to use for the entire run
time of the application.

* Add DDHotKey library to the project. Just copy the files in from the
  latest HEAD@e0481f648e0bc7e55d183622b00510b6721152d8.
* Only add DDHotKeyCenter.{h,m} & DDHotKeyUtilities.{h,m} to the "Low
  Battery Yup.d" target as the *TextField file is only useful for a UI
  to choose a hotkey, and we don't have a UI in this target.
* Set the DDHotKey* files to use ARC when compiling since they require
  it. This was done by going to Build Phases -> Compile Sources and
  adding this flag for both files:

      -fobj-arc

  this I figured out thanks to the following SO post:

    http://stackoverflow.com/questions/6448874/disable-automatic-reference-counting-for-some-files/10255815#10255815

* Link Carbon.framework because DDHotKey depends on it to register
  global hotkeys
* Move our mouse moving & clicking code to a new method that gets used
  as the global hotkey action
* Fix a runtime error caused by MainMenu.xib not being available (as a
  result of f0e8b5188e6fb984511eb01849380669e69632a6). To do this, we
  modify `main.m` to bypass the check for MainMenu.xib as described in
  this SO post:

    http://stackoverflow.com/questions/6945872/cocoa-app-without-a-mainmenu-xib/6946016#6946016

* Delete the `window` `IBOutlet` since we no longer have a MainMenu.xib
  and don't have a window in this app.

Since we alloc-inited the mouse, we need to make sure to release it when
we're done with it. Forgot to do this when I originally wrote this bit.

Since this is a backround app
(3db243f3c84f7ab36747f4badfd4f57a26563821), we don't have a UI and have
no need for any nib files.

We'll make an additional target as a separate application that does
have a UI and will allow customisation of the global hotkey.

Modify the coordinates such that instead of clicking the center of the
screen, we click the OK button on the low battery warning dialog.

Rename the method according to its new intent.

TODO: This probably doesn't work on other displays that have different
resolutions. We need to check that and figure out a cross-display
solution.